Internet Engineering Task Force (IETF) K. Wolf 
Request for Comments: 6197 nic.at 
Category: Experimental April 2011 
ISSN: 2070-1721 


Location-to-Service Translation (LoST) Service List Boundary Extension 
Abstract 


Location-to-Service Translation (LoST) maps service identifiers and 
location information to service contact URIs. If a LoST client wants 
to discover available services for a particular location, it will 
perform a <listServicesByLocation> query to the LoST server. 
However, the LoST server, in its response, does not provide context 
information; that is, it does not provide any additional information 
about the geographical region within which the returned list of 
services is considered valid. Therefore, this document defines a 
Service List Boundary that returns a local context along with the 
list of services returned, in order to assist the client in not 
missing a change in available services when moving. 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6197. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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Les 


Introduction 


Since the LoST protocol [RFC5222] employs the Service Boundary 
concept in order to avoid having clients continuously trying to 
refresh the mapping of a specific service, a Service List Boundary 
mechanism provides similar advantages for Service Lists. 


Location-based service providers, as well as Public Safety Answering 
Points (PSAPs), only serve a specific geographic region. Therefore, 
the LoST protocol defines the Service Boundary, which indicates the 
service region for a specific service URL. However, not all services 
are available everywhere. Clients can discover available services 
for a particular location via the <listServicesByLocation> query in 
LoST. The LoST server returns a list of services that are available 
at this particular location, but the server does not provide any 
additional information about the geographical region within which the 
returned Service List is considered valid. This may lead to the 
situation where a client initially discovers all available services 
via the <listServicesByLocation> query, and then moves to a different 
location (while refreshing the service mappings), but without 
noticing the availability of other services. The following imaginary 
example illustrates the problem for emergency calling: 


The client is powered-up, does location determination (resulting in 
location A), and performs an initial <listServicesByLocation> query 
with location A requesting urn:services:sos. 


The LoST server returns the following list of services: 


urn:service:sos.police 
urn:service:sos.ambulance 
urn:service:sos.fire 


The client does the initial LoST mapping and discovers the 
dialstrings for each service. Then the client moves, refreshing the 
individual service mappings when necessary as specified by the 
Service Boundary. However, when arriving in location B (close to a 
mountain), service sos.mountainrescue, which was not available in 
location A, becomes available. Since the client is only required to 
refresh the mappings for the initially discovered services, the new 
service is not detected. Consequently, the dialstring for the 
mountain-rescue service is not known by the client. Hence, the 
client is unable to recognize an emergency call when the user enters 
the dialstring of the mountain-rescue service, and the emergency call 
may fail altogether. 
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Note that the Service Boundary (service region for an individual 
service) cannot be considered as an indicator for the region for 
which a specific Service List is valid. The Service List may even 
change within the Service Boundary of another service. For example, 
the ambulance mapping is valid for a whole state, but for a part of 
the state there is an additional mountain-rescue service. 


Consequently, there are two ways to tackle this issue: 


o Clients continuously poll for the Service List, although it may 
not have changed. 


o The server sends a message containing boundary information that 
tells the client that the Service List does not change inside this 
area. 

2. Terminology 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 

"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

document are to be interpreted as described in RFC 2119 [RFC2119]. 


3. LoST Extensions 


This section describes the necessary extensions to the LoST protocol 
in order to support the Service List Boundary in a similar way as the 
Service Boundary. Extensions defined in this document are declared 
in the new XML namespace urn:ietf:params:xml:ns:lostl:slb. 


3.1. Extensions to <listServicesByLocation> 


The query <listServicesByLocation> may contain an additional 
<serviceListBoundaryRequest> element to additionally request the 
boundary for the Service List based on the location provided, with 
the resulting location for the list presented either by value or by 
reference. In the example below, the value of the ’type’ attribute 
of the <serviceListBoundaryRequest> element is set to "value": 
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<?xml version="1.0" encoding="UTF-8"?> 
<listServicesByLocation 
xmlns="urn:ietf:params:xml:ns:losti" 
xmlns:gml="http://www.opengis.net/gml" 
xmins:slb="urn:ietf:params:xml:ns:lostl:slb" 
recursive="true"> 
<location id="5415203asdf£548" profile="civic"> 
<civicAddress xml:lang="en" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr"> 
<country>AT</country> 
<Al>Lower Austria</Al1> 
<A2>Bruck an der Leitha</A2> 
<A3>Wolfsthal</A3> 
<RD>Hauptplatz</RD> 
<HNO>1</HNO> 
<PC>2412</PC> 
</civicAddress> 
</location> 
<service>urn:service:sos</service> 
<slb:serviceListBoundaryRequest type="value"/> 
</listServicesByLocation> 


A <listServicesByLocationResponse> with the addition of one 
<serviceListBoundary> element is shown below: 


<?xml version="1.0" encoding="UTF-8"?> 
<listServicesByLocationResponse 
xmlns="urn:ietf:params:xml:ns:lostl1" 
xmilns:slb="urn:ietf:params:xml:ns:lostl:slb"> 
<serviceList> 
urn:service:sos.ambulance 
urn:service:sos.fire 
urn:service:sos.gas 
urn:service:sos.mountain 
urn:service:sos.poison 
urn:service:sos.police 
</serviceList> 
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<path> 
<via source="resolver.example"/> 
<via source="authoritative.example"/> 
</path> 
<locationUsed id="5415203asdf548"/> 
<slb:serviceListBoundary profile="civic" 
expires="2012-01-01T00:00:002Z"> 
<civicAddress xml:lang="en" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr"> 
<country>AT</country> 
<Al>Lower Austria</Al1> 
</civicAddress> 
</slb:serviceListBoundary> 
</listServicesByLocationResponse> 


The response above indicates that the Service List is valid for Lower 
Austria. The <listServicesByLocation> request needs to be repeated 
by the client only when moving out of Lower Austria. However, the 
mappings of the services themselves may have other service 
boundaries. Additionally, the ’expires’ attribute indicates the 
absolute time when this Service List becomes invalid. 


The response MAY contain multiple <serviceListBoundary> elements for 
alternative representation, each representing the boundary ina 
specific location profile. However, multiple locations inside a 
<serviceListBoundary> element are considered to be additive. 


The boundary can also be requested by reference when setting the 
value of the ’type’ attribute of the <serviceListBoundaryRequest> 
element to "reference" (which is the default in case the attribute is 
omitted). The response will contain a <serviceListBoundaryReference> 
element with a ’serviceListKey’ attribute (described in Section 3.2), 
as shown below. 


<?xml version="1.0" encoding="UTF-8"?> 
<listServicesByLocationResponse 
xmlns="urn:ietf:params:xml:ns:lost1" 
xmilns:slb="urn:ietf:params:xml:ns:lostl:slb"> 
<serviceList> 
urn:service:sos.ambulance 
urn:service:sos.fire 
urn:service:sos.gas 
urn:service:sos.mountain 
urn:service:sos.poison 
urn:service:sos.police 
</serviceList> 
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<path> 
<via source="resolver.example"/> 
<via source="authoritative.example"/> 
</path> 
<locationUsed id="5415203asdf548"/> 
<slb:serviceListBoundaryReference 
source="authoritative.example" 
serviceListKey="123567890123567890123567890" /> 
</listServicesByLocationResponse> 


3.2. Retrieving the <serviceListBoundary> via <getServiceListBoundary> 


In order to retrieve the boundary corresponding to a specific 
'serviceListKey’, the client issues a <getServiceListBoundary> 
request to the server identified in the ’source’ attribute of the 
<serviceListBoundaryReference> element, similar to the 
<getServiceBoundary> request. 


An example is shown below: 


<?xml version="1.0" encoding="UTF-8"?> 
<getServiceListBoundary 
xmlns="urn:ietf:params:xml:ns:lostl:slb" 
serviceListKey="123567890123567890123567890"/> 


The LoST server response is shown below: 


<?xml version="1.0" encoding="UTF-8"?> 
<getServiceListBoundaryResponse 
xmlns="urn:ietf:params:xml:ns:lost1l:slb"> 
<serviceListBoundary profile="Civic" expires="2012-01-01T00:00:00Z"> 
<civicAddress xml:lang="en" 
xmlns="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr"> 
<country>AT</country> 
<Al>Lower Austria</Al1> 
</civicAddress> 
</serviceListBoundary> 
<path xmlns="urn:ietf:params:xml:ns:lostl1"> 
<via source="resolver.example"/> 
<via source="authoritative.example"/> 
</path> 
</getServiceListBoundaryResponse> 
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The ’serviceListKey’ uniquely identifies a Service List Boundary, as 
the ‘key’ does for the Service Boundary (see Section 5.6 of 

RFC 5222). Therefore, the ’serviceListKey’ is a random token with at 
least 128 bits of entropy [RFC4086] and can be assumed globally 
unique. Whenever the boundary changes, a new ’serviceListKey’ MUST 
be assigned. 


Note: Since LoST does not define an attribute to indicate which 
location profile the client understands in a <getServiceBoundary> 
request, this document also does not define one for the 
<getServiceListBoundary> request. 


3.3. <serviceListBoundary> 


For a particular <listServicesByLocation> query, the Service List 
Boundary information that gets returned indicates that all the 
service identifiers returned in the <serviceList> element are the 
same within this geographic region. A Service List Boundary may 
consist of geometric shapes (both in civic and geodetic location 
format), and may be non-contiguous, like the Service Boundary. 


The mapping of the specific services within the Service List Boundary 
may be different at different locations. 


The server MAY return the boundary information in multiple location 
profiles, but MUST use at least one profile that the client used in 
the request in order to ensure that the client is able to process the 
boundary information. 


There is no need to include boundary information ina 
<listServicesResponse>. The <listServices> request is purely for 
diagnostic purposes and does not contain location information at all, 
so boundary information cannot be calculated. 


Also note that the Service List Boundary is OPTIONAL, and the LoST 
server may return it or not, based on its local policy -- as is the 
case with the Service Boundary. However, especially for emergency 
services, the Service List Boundary might be crucial to ensure that 
moving clients do not miss changes in the available services. 
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3.4. Implementation Considerations 


The subsections below discuss implementation issues for the LoST 
server and client for Service List Boundary support. 


3.4.1. Server Side 


The mapping architecture and framework [RFC5582] states that each 

tree announces its coverage region (for one type of service, e.g., 
sos.police) to one or more forest guides. Forest guides peer with 
each other and synchronize their data. Hence, a forest guide has 

sufficient knowledge (it knows all the services and their coverage 
regions) to answer a <listServicesByLocation> query and to add the 
<serviceListBoundary> or <serviceListBoundaryReference> as well. 


The calculation of the largest possible area for which the Service 
List stays the same might be a complex task. An alternative would be 
to return smaller areas that are easier to compute. In such a case, 
some unnecessary queries to the LoST server will be a consequence, 
but the main purpose of the Service List Boundary is still achieved: 
to never miss a change of available services. Thus, the server 
operator may specify a reasonable trade-off between the effort to 
generate the boundary information and the saved queries to the LoST 
server. 


For example, in some countries the offered services may differ in 
adjacent counties (or districts, cantons, states, etc.). Their 
borders may be suitable as a Service List Boundary as well, even 
though some adjacent counties offer the same services. 


Other countries might have different structures, and the generation 

of the Service List Boundary might follow other rules as long as it 

is ensured that a client is able to notice any change in the Service 
List when moving. 


3.4.2. Client Side 


A mobile client that already implements LoST and evaluates the 
<serviceBoundary> has almost everything that is needed to make use of 
the Service List Boundary. Since the integration into LoST follows 
the concept of the <serviceBoundary> (and also makes use of the same 
location profiles), only the additional <serviceListBoundary> needs 
to be evaluated. Whenever moving outside a Service List Boundary, 
the client performs a new <listServicesByLocation> query with the new 
location information in order to determine a change in available 
services. 
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4. 


Security and Privacy Considerations 


Security considerations for LoST are discussed in [RFC5222]. This 
document extends LoST to also carry Service List Boundaries (and 
requests for them). These Service List Boundaries are calculated by 
the server based on the individual Service Boundaries and sent to 
clients in case the local policy allows this. Therefore, it is 
generally considered to have the same level of sensitivity as for the 
Service Boundary and thus the same access control and confidentiality 
requirements as the base LoST protocol. As a result, the security 
measures incorporated in the base LoST specification [RFC5222] 
provide sufficient protection for LoST messages that use the Service 
List Boundary extension. 


IANA Considerations 
TANA has taken two actions: an XML schema registration anda 


namespace registration, according to the description in the following 
sections. 


.1. Relax NG Schema Registration 


IANA has registered the following Relax NG Schema in the IETF XML 
Registry [RFC3688]: 


URI: urn:ietf:params:xml:schema:lost1:slb 


Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 
(karlheinz.wolf@nic.at) 


Relax NG Schema: 
BEGIN 


<?xml version="1.0" encoding="UTF-8"?> 

<grammar 
xmlns="http://relaxng.org/ns/structure/1.0" 
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" 
xmlins:slb="urn:ietf:params:xml:ns:lostl:slb" 
ns="urn:ietf:params:xml:ns:lost1" 
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> 

<include href="lost.rng"> 


Wolf Experimental [Page 10] 


RFC 6197 serviceListBoundary April 2011 


<!-- redefinition of LoST elements --> 
<start> 
<choice> 

<ref name="findService"/> 
<ref name="listServices"/> 
<ref name="listServicesByLocation"/> 
<ref name="getServiceBoundary"/> 
<ref name="findServiceResponse"/> 
<ref name="listServicesResponse"/> 
<ref name="listServicesByLocationResponse"/> 
<ref name="getServiceBoundaryResponse"/> 
<ref name="errors"/> 
<ref name="redirect"/> 


<!-- New in RFC 6197 --> 
<ref name="getServiceListBoundary"/> 
<ref name="getServiceListBoundaryResponse"/> 
</choice> 
</start> 


<define name="listServicesByLocation"> 
<element name="listServicesByLocation"> 
<ref name="requestLocation"/> 
<ref name="commonRequestPattern"/> 
<optional> 
<attribute name="recursive"> 
<data type="boolean"/> 
<a:defaultValue>true</a:defaultValue> 
</attribute> 
</optional> 


<!-- New in RFC 6197 --> 
<optional> 
<ref name="serviceListBoundaryRequest"/> 
</optional> 
</element> 
</define> 


<define name="listServicesByLocationResponse"> 
<element name="listServicesByLocationResponse"> 
<ref name="serviceList"/> 
<ref name="commonResponsePattern"/> 
<ref name="locationUsed"/> 
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<!-- New in RFC 6197 --> 
<optional> 
<choice> 
<ref name="serviceListBoundary"/> 
<ref name="serviceListBoundaryReference"/> 
</choice> 
</optional> 
</element> 
</define> 
</include> 


<define name="ServiceListBoundaryRequest"> 
<element name="slb:serviceListBoundaryRequest"> 
<optional> 
<attribute name="type"> 
<choice> 
<value>value</value> 
<value>reference</value> 
</choice> 
<a:defaultValue>reference</a:defaultValue> 
</attribute> 
</optional> 
</element> 
</define> 


<define name="serviceListBoundary"> 


<oneOrMore> 
<element name="slb:serviceListBoundary"> 
<optional> 
<ref name="expires"/> 
</optional> 


<ref name="locationInformation"/> 
<ref name="extensionPoint"/> 
</element> 
</oneOrMore> 
</define> 


<define name="serviceListBoundaryReference"> 
<element name="slb:serviceListBoundaryReference"> 
<ref name="source"/> 
<attribute name="serviceListKey"> 
<data type="token"/> 
</attribute> 
<ref name="extensionPoint"/> 
</element> 
</define> 
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<define name="getServiceListBoundary"> 
<element name="slb:getServiceListBoundary"> 
<attribute name="serviceListKey"> 
<data type="token"/> 
</attribute> 
<ref name="extensionPoint"/> 
</element> 
</define> 


<define name="getServiceListBoundaryResponse"> 
<element name="slb:getServiceListBoundaryResponse"> 
<ref name="serviceListBoundary"/> 
<ref name="path"/> 
<ref name="extensionPoint"/> 
</element> 

</define> 

</grammar> 


END 


5.2. Namespace Registration 


2011 


IANA has registered the following namespace (below the LoST namespace 


defined in [RFC5222]) in the IETF XML Registry [RFC3688]: 
URI: urn:ietf:params:xml:ns:lostl:slb 


Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf 
(karlheinz.wolf@nic.at) 
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XML: 
BEGIN 


<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" 
"http://www.w3.org/TR/xhtml-basic/xhtml-basicl0.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtm1"> 
<head> 
<meta http-equiv="content-type" 
content="text/html; charset=iso-8859-1"/> 
<title>LoST Service List Boundary Namespace</title> 
</head> 
<body> 
<hl>Namespace for the LoST Service List Boundary</h1> 
<h2>urn:ietf:params:xml:ns:lost1l:slb</h2> 
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6197.txt"> 
RFC 6197</a>.</p> 
</body> 
</html> 


END 
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